歐嗨呦～哇搭西哇「小笠宏樹」得斯！
今天要來聊聊的是這個異想世界的基礎「部門」。

這是個簡單的開始，某天突然覺得在公司這個架構中，部門就像是其中的一個一個的Class，接著一個接著一個的點子就開始冒出來了。

部門 vs Class

與外部的溝通

對於外部來說會有某些特定的方式去驅動這個部門做事情，這就像是部門中的public fun。

對於內部的邏輯

對於內部來說部門會有它內部的邏輯和分工方式去處理從外面帶進來的資料，並且經過處理後看要傳遞回去答案或是通知別的部門後續的行為，這其實就跟Class的private fun是很類似的。

規模

在Class的大小上我們常看到書上會寫一個Class盡量不要太大，如果太大那就表示你可以切成好幾個Class，這其實也可以用部門的方式去解釋這件事。
假設有個部門太過龐大時，你會發現一些麻煩的狀況

1. 公司不管做什麼事你都必須經過這個部門去做事，無法繞開。
2. 部門這麼龐大所需要處理的邏輯和所需要給予部門的資料也會趨向複雜，這會導致外部的人要跟這個部門合作必須小心翼翼準備資料，而且還會浪費許多時間在溝通跟拿到回應上。
3. 再來是部門的內部也會有許多不同領域的人參雜其中，這會導致部門裡面的合作邏輯十分雜亂，而且很容易因為一點流程改動發生錯亂。

剩下的發散思考就交給大家自由印證哩～

人員

通常我們會希望一個部門裡面的人數越小越好，盡量剛好滿足部門的工作最好，但不太可能，因為總是會有一些不常出現的事件導致我們非得在部門裡面有多一點的人力或資源在裡面，這其實就跟Class的變數一樣，通常因為工程師的堅持(其實是IDE的灰色字強迫症)我們會希望變數越少越好，但變數數量的決定權通常都來自於那幾個少用的特殊fun，或是特殊的少量邏輯段，因此當特殊fun越來越多時會發生什麼事，工程師便會嚷著開新的Class把這些fun提出去外部做。

最後還是要補充一下，其實上面雖然用人員與變數做類比，但事實上員工可以做的事比變數複雜得多，因此如果需要處理到細緻的部門內人員的管理，不妨把每個人都當作一個Class再重新去思考這件事吧～

好哩～
下個篇章我們將進入fun的定義～
大家可以提前去猜想到底fun對比於公司內會有什麼常見的情況，說不定你的想法會跟我一模一樣喔！